Program operators for composing abstractions

ABSTRACT

Programming abstractions with at least one expression are composed to a single abstraction using a composition operator. Expressions from the abstractions are unfolded by removing the prefix of each abstraction and substituting formal parameter names in each expression with a common parameter name to define open variables. The unfolded expressions are transformed to a reduced expression using a composition pattern that tunes semantics of the composition operators. The reduced expression is nested in the single abstraction by: appending a selected prefix of the composed abstraction to the reduced expression, binding the open variables of the reduced expression to the formal parameter of the selected prefix, and computing the type of the formal parameter of the selected prefix.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] Cross-reference is made to U.S. patent application Ser. Nos.10/046,314, entitled “Symmetrical Structural Pattern Matching”,10/046,191 entitled “Bi-Valuation Of Programming Statements”, which areassigned to the same assignee as the present invention and incorporatedherein by reference. Cross-reference is also made to U.S. patentapplication filed concurrently herewith and entitled “Program CompilerWith Abstraction Composer”, which is assigned to the same assignee asthe present invention and incorporated herein by reference.

BACKGROUND OF INVENTION

[0002] The present invention relates generally to software programminglanguages, and more particularly, to a programming language withoperators adapted to compose programming abstractions.

[0003] Central to all programming languages is the concept of“programming abstractions”. Programming abstractions as used hereindescribe functional behavior in computer programs through, for example,functions, procedures, or methods. Programming abstractions have thequalities of software code embedding, factorization, and reuse.

[0004] Code embedding refers to the use of programming abstractions(also referred to herein as “abstractions”) as building blocks, whereabstractions are able to call each other. Code factorization refers tothe avoidance of code duplication associated with abstractions in aprogram. Code reuse refers to the avoidance of duplicating abstractionsto develop additional functionality.

[0005] More specifically, code factorization avoids the duplication of“n” similar code segments if they are needed at “n” different locationsin a software program. These different segments can be transformed intoa common abstraction which can be invoked “n” times at a single locationin the software program. This operation is called an abstraction becausesome of the programming instructions are changed in order to operate onvariables instead of values. These variables constitute the executionenvironment of the abstraction, where the value of the variables isspecified at runtime.

[0006] For example, the operation “10+1” can be abstracted into anabstraction called a λ-abstraction (i.e., lambda-abstraction) that hasthe form “λ x:int.x+1” , where 10 is now defined as the variable “x” oftype integer (i.e., “int”). In effect, the lambda-abstraction hasgeneralized the operation “10+1” making it applicable to any integer,instead of a constant (e.g., 10).

[0007] Consequently if this lambda-abstraction is called “F”, then F(10) will compute 11 and F (11) or F (F(10)) will compute 12.

[0008] It is therefore advantageous to define computer programs usingabstractions to simplify software design by breaking down a complexmonolithic program into smaller sub-programs. In addition, programmingusing abstractions has the additional benefit of simplifying qualityassurance testing. For instance, testing a plurality of smallsub-programs is easier than testing a large monolithic program becausethe context of each sub-program is more explicit and the branchingcomplexity is simplified.

[0009] Besides code factorization, abstractions enable code reuse. Thatis, previously created abstractions can be reused when new software isdeveloped by programmers. The reuse of abstractions may be as simple ascopying abstractions from a repository of abstractions or from anexisting program. In addition, the reuse of abstractions may involve theuse of function previously created to create new function.

[0010] The creation of a new abstraction that combines the function oftwo or more existing abstractions is defined herein as the “compositionof programming abstractions”. Current software programming techniquesare poorly adapted to facilitate the composition of abstractions in astructured and a formal manner; indeed, existing techniques achievereuse through two basic techniques that simply reuse existing approachesfor composing operators that work either by duplicating code definingabstractions or by directly calling abstractions (e.g., by nestingcalls). These current techniques for composing abstractions results inthe production of unnecessary code at compile time.

[0011] For example, assume an existing ∇-abstraction (i.e.,nabla-abstraction) “P” that takes any integer “x” and computes itsdouble as output “y” is defined as “P=∇ x:int, y:int.(y:=2*x)”.

[0012] Existing techniques for creating a new abstraction “PP” thatencapsulates two subsequent calls to the abstraction “P” would bedefined as “PP=∇ x:int, y:int.(y:=P(P(x))”. Execution of the composedabstraction PP(3) would produce 12. However this method for composingabstractions could be more efficient because P(P(x)) requires moreinstructions than necessary to carry out the operation.

[0013] Accordingly, it would be desirable to provide a programminglanguage and compiler adapted to compose programming abstractions. Sucha programming language and compiler would advantageously speed andsimplify program development and maintenance by facilitating thecombination of existing abstractions in a structured and formal manner.

SUMMARY OF INVENTION

[0014] In accordance with the invention, there is provided programoperators, and a compiler therefor, for composing programmingabstractions. Advantageously, the program operators for composingabstractions provide a definitional framework that shows thatabstractions are reused and the manner in which they are reused,simplifying program maintenance through increased legibility. Inaddition, the compilation of the composition of abstractions using theprogram operators produces a composed abstraction after compilation thatis functionally equivalent to existing approaches for composingoperators but computationally different, thereby increasing programefficiency at runtime.

[0015] For example, composing the existing delta-abstraction “P”(defined above) using a composition operator “pipe” (described in detailbelow) results in source code that defines a new abstraction as “PP′=Ppipe P”. This definition explicitly shows the reuse of programmingabstractions in the source code. In addition after compilation, theabstraction PP′ reduces to “PP′=∇ x:int, y:int.(var a=0.a:=2*x; y:=2*a)”which is functionally equivalent yet computationally more efficient thanthe abstraction PP (defined above).

[0016] In accordance with one aspect of the invention, there is provideda method, apparatus and article manufacture therefor, for composingprogramming abstractions. A composition operation is defined forcomposing a first abstraction and a second abstraction with a selectedcomposition operator. Each abstraction has a form, a prefix, and atleast one expression. The expressions from the first and thesecond-abstractions are unfolded by: removing the prefix of eachabstraction, and substituting formal parameter names in each expressionwith a common parameter name to define open variables. The unfoldedexpressions are transformed to a reduced expression using a compositionpattern that tunes semantics of the selected composition operator. Aprefix is selected that depends on the selected composition operator andthe form of the first abstraction and the second abstraction. Theselected prefix has a formal parameter with a type. The reducedexpression is nested in a third abstraction that composes the firstabstraction and the second abstraction by: appending the selected prefixto the reduced expression, binding the open variables of the reducedexpression to the formal parameter of the selected prefix; and computingthe type of the formal parameter of the selected prefix.

BRIEF DESCRIPTION OF DRAWINGS

[0017] These and other aspects of the invention will become apparentfrom the following description read in conjunction with the accompanyingdrawings wherein the same reference numerals have been applied to likeparts and in which:

[0018]FIG. 1 illustrates a general purpose computer for carrying out thepresent invention;

[0019]FIG. 2 illustrates a detail view of the multi-stage compiler shownin FIG. 1;

[0020]FIG. 3 illustrates a logical outline of a method for performing anabstraction composition operation shown in FIG. 2;

[0021]FIG. 4 is a flow diagram of the acts performed in the logicoutline shown in FIG. 3 for carrying out the composition ofabstractions;

[0022]FIG. 5 illustrates a binary tree syntactically and illustrativelyfor encoding the arithmetic expression “a=b+10*c”;

[0023]FIGS. 6 and 7 illustrate resulting binary trees syntactically andillustratively when two different transformers are applied to the binarytree shown in FIG. 5; and

[0024]FIG. 8 illustrates the resulting binary tree syntactically andillustratively when the composition of two transformers is applied tothe binary tree shown in FIG. 5.

DETAILED DESCRIPTION OUTLINE OF DETAILED DESCRIPTION

[0025] A. Operating Environment

[0026] A.1 Multi-Stage Compiler

[0027] A.2 Method For Composing Operators

[0028] A.3 Detailed Example

[0029] B. General Syntax And Operational Semantics

[0030] C. Type System

[0031] C.1 Defining Sub-Type Relations

[0032] C.2 Typing Rules For Defining Well Typed Properties of Terms

[0033] D. The Composition Of Functional Abstractions

[0034] D.1 Typing Of Composition Operators

[0035] D.2 Computational Equivalence

[0036] D.3 Application To The Computation Of Numerical Series

[0037] D.4 Handling Subtype Polymorphism (Generalization)

[0038] E. Extending The Calculus With Imperative Expressions

[0039] E.1 Computing Environment

[0040] E.2 Syntactic Expressions

[0041] E.3 Operational Semantics

[0042] E.4 Type System

[0043] F. Polymorphic Composition of Nabla-Abstractions

[0044] F.1 Semantics

[0045] F.2 Typing

[0046] G. A Set Of Composition Operators

[0047] H. Safety Properties Of The Calculus

[0048] H.1 General Type Preservation Property

[0049] H.2 Strong Type Soundness Of The Core Calculus

[0050] H.3 Weak Type Soundness Of The Whole Calculus C/F(E)

[0051] I. Polymorphic Composition Of Records

[0052] I.1 Definition

[0053] I.2 Using Record Polymorphism In Pam Composition

[0054] J. Illustration Of A Modeling Tree Transformer

[0055] K. Miscellaneous

[0056] A. Operating Environment

[0057]FIG. 1 illustrates a general purpose computer 110 for carrying outthe present invention. The general purpose computer 110 includeshardware 112 and software 114. The hardware 112 is made up of aprocessor (i.e., CPU) 116, memory 118 (ROM, RAM, etc.), persistentstorage 120 (e.g., CD-ROM, hard drive, floppy drive, tape drive, etc.),user I/O 122, and network I/O 124. The user I/O 122 can include akeyboard 126, a pointing device 128 (e.g., pointing stick, mouse, etc.),and the display 130. The network I/O 124 may for example be coupled to anetwork 132 such as the Internet.

[0058] The software 114 of the general purpose computer 110 includes anoperating system 136, a source code editor (and debugger) 138, and amulti-stage compiler 140. The operating system 136 permits processor 116to allow a user of the general purpose computer 110 to compose sourcecode using the source code editor 138. The source code, which is storedin either memory 118 or persistent storage 120, is compiled by themulti-stage compile 140.

[0059] A.1 Multi-Stage Compiler

[0060]FIG. 2 illustrates a detail view of the multi-stage compiler shownin FIG. 1. The multi-stage compiler includes a tokenizer 206, a parser208, an importer 210, a type checker 212, a composer 214, a partialevaluator 215, an intermediate format generator 216 that generatesintermediate code 220, a code optimizer, and a code generator 218 thatgenerates executable code 204, the details of which are described below.

[0061] The multi-stage compiler 140 takes as input source code 202 andproduces as output executable code 204. The multi-stage compiler mayeither operate statically (i.e., during a composition or analysis stageof language processing) or dynamically (i.e., during execution of theexecutable code). The code generator 218 may produce: executable codethat constitutes machine specific operating instructions (i.e.,op-codes), byte-codes that may be executed on an interpreter, or acombination of op-codes or byte-codes.

[0062] In accordance with the invention, the source code 202 isformulated with at least one abstraction composition operation 222 usingfor example the source code editor 138, which may be any conventionaltext editing program. In general, the abstraction composition operationthat is defined in the source code 202 composes at least a firstabstraction 224 and a second abstraction 226 using a compositionoperator 228.

[0063] During compilation of the source code 202, the composer 214 inthe multi-stage compiler 140 reduces the abstraction compositionoperation 222 to a new abstraction 230. The composed abstraction 230 islater compiled into an executable form by the other elements of themulti-stage compiler 140 as described in more detail below.

[0064] In operation, the multi-stage compiler 140 receives as inputsource code 202 that is formulated with at least one instructioncomposing two abstractions (e.g., as shown at 222). Recognition of thecontents of the source code is broken into two stages. Initially, thetokenizer 206 segments the source code into a sequence of taggedsegments. The tagged segments are used by the parser 208, which isconcerned with the structure of the source code, to build a concretetree. The resulting concrete tree is in computable form and contains allof the useful information forming part of the source code that isnecessary to formulate executable or intermediate code.

[0065] After tokenizing and parsing at 206 and 208, elements referred toin the source code that are external to the source code are resolved bythe importer 210 by accessing the intermediate code 220. Subsequently,the type checker 212 applies a type checking process to the concretetree. The type checking process traverses an abstract representation(i.e., an abstract tree) of the concrete tree, possibly in multiplepasses, and decorates the abstract tree with types that add informationrelated to the type of expressions on the abstract tree using theparsing and tokenizing information to define a decorated tree. Inaddition, the type checker 212 determines whether an expression is “welltyped”, using known methods for type checking that allows finding,legitimizing, and propagating types.

[0066] The type checker 212 delegates the processing of abstractioncomposition operations (e.g., abstraction composition operation 222)that are on the decorated tree to the composer 214. Thus, when the typechecker 212 detects that some expressions in the source code are definedthrough composition operators, the type checker 212 passes the decoratedtree for processing by the composer 214. The composer 214 reduces theabstraction composition operation 222 on the decorated tree into a newcomposed abstraction 230 that is decorated with types.

[0067] The new expressions and types added to the decorated tree by thecomposer 214 are then evaluated by the type checker 212 to determinewhether those new expressions are well typed. In accordance with theinvention, the composition of two abstractions may take place if theresulting composition is well typed. The type system described hereindefines a framework for determining whether a composed expression iswell typed as defined below. Generally, a well-typed expressionsatisfies a weak type soundness property, which provides that eachtransition step preserves typing.

[0068] The type checker 212 has the ability to accept subtypes and usesthe type system defined below to distinguish the typing of abstractions.For example, the type system distinguishes between non-recursive andrecursive abstractions. The advantage of distinguishing between thesetwo types of abstractions is that it increases the precision of the typechecking system, thereby allowing the type checker 212 to assert thatthe composed abstraction 230 is the correct composition of theabstraction composition operation 222.

[0069] Once all composition operations have been processed anddetermined to be well typed, the type checker 212 passes the decoratedtree to the partial evaluator 215 which pre-evaluates languageinstructions in the decorated tree to reduce their complexity. Thedecorated tree is then evaluated by the intermediate format generator216 to generate intermediate code 220 (i.e., a linear form of thedecorated tree) for later importation by other programs. In addition,the decorated tree is evaluated by the code optimizer 217, which furtherevaluates the language instructions in the decorated tree to optimizecertain aspects (e.g., new syntactic figures that may issue from thecomposition operation). Advantageously, the optimization performed bythe code optimizer 217 takes place after composition by the composer214, thereby further optimizing any composed abstractions it generates.The decorated tree is then input to the code generator 218 to generateexecutable code 204 (i.e., object code) for execution, for example, byprocessor 116 of the general purpose computer 110.

[0070] It will be appreciated by those skilled in the art thatfunctional languages (e.g., ML family), which do not use explicittyping, may use the composition operators described herein withouthaving to specify type operations. In an alternate embodiment of themultistage compiler 140, the type of expressions is deduced entirelyfrom the expressions themselves using a modified type checker thatguesses (i.e., infers) the best types. In this alternate embodiment, themulti-stage compiler 140 accommodates such functional languages byhaving the modified type checker reevaluate the decorated tree afterbeing processed by the composer 214 to re-infer types.

[0071] A.2 Method For Composing Operators

[0072]FIG. 3 illustrates a logical outline of a method for performingthe abstraction composition operation 222 shown in FIG. 2 that isperformed by the composer 214. FIG. 4 is a flow diagram of the actsperformed in the logic outline shown in FIG. 3 for carrying out thecomposition of a plurality of abstractions. FIGS. 3 and 4 are referredto simultaneously below.

[0073] Initially at 402 in FIG. 4, a composition operation that composesa plurality of abstractions with a composition operator is defined asshown in FIGS. 2 and 3 at 222. It will be appreciate that thecomposition operation 222 could include two or more abstractions thatare composed according to one or more composition operators.

[0074] Composition operators are defined below using the symbols:

,

and

. Each composition operator may have a subscript “E” (e.g.,

_(E)) that defines a “composition pattern” that is used to tune thesemantics of the composition operator. The absence of the compositionpattern “E” in the subscript of a composition operator (e.g.,

) indicates that the composition pattern “E” is an identity pattern(i.e., no tuning is performed to the semantics of the compositionoperator).

[0075] In addition, the composition operator may specify a “typecombination relation” in its superscript. The type combination relationdescribes the manner in which parameter types of the compositionoperator are to be combined. One type combination relation is specifiedfor each parameter defined by the composition operator. Each typecombination relation specified indicates how to determine the type aparameter of the composed abstraction will take. As defined herein, thetype combination relation is defined using the symbols ⊕, whichrepresents the lowest common subtype, and

, which represents the greatest common subtype, and the symbols * and ⋄,that range over {⊕,

}. The absence of either of these symbols in the superscript of acomposition operator indicates that the types during the composition ofthe parameters do not change.

[0076] At 404 in FIG. 4, each expression (e.g., 302 and 304) in eachabstraction (e.g., 224 and 226) defined in the abstraction compositionoperation 222 are unfolded. Unfolding an expression from an abstractioninvolves: (a) removing the prefix of the abstraction and (b)substituting formal parameter names in each expression with a common(i.e., fresh) parameter name to define open variables. In someembodiments, the formal parameter names may be substituted for more thanone common parameter name. Act 404 in FIG. 3 is illustrated in FIG. 3 byunfolding the expressions 302 and 304 into the expressions 306 and 308,respectively.

[0077] At 406 in FIG. 4, the unfolded expressions (e.g., expressions310) are transformed to a reduced expression (e.g., reduced expression312) using a composition pattern that tunes the semantics of thecomposition operator. In some instances, this transformation mayintroduce information that specifies how to combine parameter types.Also in some instances, this transformation may involve using acomposition pattern that is an identity pattern.

[0078] At 408 in FIG. 4, a prefix is selected (i.e., the selectedprefix) that depends on (a) the composition operator and (b) the form ofthe plurality of abstractions. Abstractions may take one of four forms:a λ-abstraction, a ∇-abstraction, and their recursive variants (whichare all defined in detail below). The selected prefix has at least oneformal parameter with a type.

[0079] At 410 in FIG. 4, the reduced expression (e.g., reducedexpression 312) is nested in a composed abstraction (e.g., composedabstraction 308) by: (a) appending the selected prefix (selected at act408) to the reduced expression; (b) binding the open variables of thereduced expression (introduced at act 404) to the formal parameter ofthe selected prefix; and (c) computing the type of the formal parameterof the selected prefix in accordance with the type combination relationspecified for the composition operator.

[0080] A.3 Detailed Example

[0081] The following example illustrates the composition of twoabstractions Abs1 and Abs2 using the composition operator

defined at [c1] below as: ( z     fresh )  E  (  e 1  [ z / x 1 ] )  ⋯  (  e n  [ z / x n ]  )      e E ⊗     ( λ     x 1 :t 1 · e 1 , …    , λ     x n : t n · e n ) → λ     z : t x · e [ c    1 ]

[0082] where:

[0083] “λ x_(n):t_(n).e_(n”) is a lambda abstraction with prefix “λx:t”, in which “λ” identifies a form of abstraction, “x” identifies aformal parameter (i.e., a parameter encapsulated in an abstraction) oftype “t”, and “e” is the expression of the abstraction,

[0084] “e_(n)[z/x_(n)]” means substitute x_(n) for z in the expressione_(n),

[0085] “

” means the terminal form of an operation (i.e., after possibly severaloperational steps) reduces to a value,

[0086] “

” identifies a type combination relation that specifies the greatestcommon subtype relation,

[0087] “e₁

e₂

” defines a lazy application in which the expression e₂ is passed by afunction without first being computed, and

[0088] “E” is a composition pattern (i.e., a lambda term thatparameterizes the composition operation

_(E)(e₁, . . . , e_(n))).

[0089] Assuming in this example the lazy application “e

e

′ is given by a [β₁] reduction defined as:

λ x:t.e₁

e₂

→e₁[e₂/x]  [β₁]

[0090] Also assuming in this example that the abstractions Abs1 and Abs2are given by:

Abs1≡λ x:any.x(where x is a formal parameter of type “any”), and

Abs2≡λ x:int.1(where x is a formal parameter of type “int”).

[0091] Further assuming in this example that the composition pattern “E”of the composition operation

is given by:

Sub≡λ x:int.λ y:int.x−y

[0092] Given the above assumptions, the composition of the abstractionsAbs1 and Abs2 is expressed as (i.e., at act 402 in FIG. 4):

(Abs1, Abs2)=

(λ x:any.x, λ x:int.1).

[0093] Initially the expressions e of each abstraction are unfolded inaccordance with the general form E

e₁[z/x₁]

e_(n)[z/x_(n)]

by (a) removing the prefix (e.g., “λ x:any” and “λ x:int”) of eachabstraction (i.e., at act 404(1) in FIG. 4) and (b) substituting theformal parameter name “x” in each expression with a common (i.e., fresh)parameter name “z” to provide the unfolded expression (e.g., (i.e., atact 404(2) in FIG. 4):

Sub

x[z/x]

1[z/x′]

.

[0094] Transforming the unfolded expression using the compositionpattern Sub provides a reduced expression (i.e., at act 406 in FIG. 4)initially in the form (after substituting “x” for “z” in the expression“e” given by “e[z/x]”):

[0095] Sub

z

1

, which after expanding in accordance with the composition pattern Subprovides:

[0096] λ x:int.y:int.x−y

z

1

, which after applying z to x in accordance with [β₁] reduction reducesto:

[0097] λ y:int.z−y

1

, and which after applying 1 for y in accordance with [β₁] reductionreduces to the reduced expression (called “e”):

z−1.

[0098] A prefix is selected with a value that depends on the compositionoperator (e.g.,

) and the form of the plurality of abstractions (e.g., Abs1 and Abs2).For this example the selected prefix is “λ x:???” (i.e., at act 408 inFIG. 4). Finally, the reduced expression is nested in an abstraction byappending the selected prefix (i.e., at act 410(1) in FIG. 4) asfollows:

[0099] λ x:???.z−1 , and binding the open variable “z” to the formalparameter “x” of the selected prefix (i.e., at act 410(2) in FIG. 4) asfollows:

[0100] λ z:???.z−1, and computing the type of the formal parameter ofthe selected prefix in accordance with the greatest common subtyperelation of types “any” and “int” (e.g., any

int≡int) (i.e., at act 410(3) in FIG. 4) as follows to provide thecomposed abstraction:

λ z:int.z−1.

[0101] B. General Syntax And Operational Semantics

[0102] Operational semantics is described herein using the SOS styledescribed in G. Plotkin's article “A structural approach to operationalsemantics”, Technical Report DAIMI-FN-19, Computer Sciences Dept., Århus university, Denmark, 1981, considering “small step” transitions inorder to cover an eventual extension to concurrent languages withinterleaving semantics.

[0103] A set of definitions is provided of a general abstract syntax ofexpressions “e” that describes basic constructs for terms of theunderlying programming language, where the notation of “e” encompassesimperative and functional expressions. The first set defined in thissection specifies functional expressions and the second set definedbelow in section E specifies imperative expressions.

[0104] An “imperative expression” as used herein generally means anexpression that involves several sequential computational steps. A“functional expression” as used herein generally means an expressionthat allows “functional style” programming (i.e., programming thatallows solution of problems to be found by defining functions andapplying parameters to those functions).

[0105] Functional expressions “e”, with types “t”, defined hereininclude: e ::= n | x | s | numerical values, variables, string litteralse*e | basic operations (* ε {+, −, *}) if e then e else e | alternationλx:t.e | fixf(x:t)=e | typed lambda abstraction and recursive variante(|e|) | e(e) | lazy and strict application e ::= true | false | booleanliterals e == e | e > e | comparisons t ::= int | string | bool |primitive types t|t | union of types T | ⊥ | t → t | t

t top and bottom type, functions, recursive functions

[0106] The definition of two different applications are describedherein: the first definition of “application” (i.e., e₁

e₂

) allows lazy application whereas the second definition of “application”(i.e., e₁(e₂)) allows strict application (i.e., where the parameter mustbe normalized to a value before substitution, where a value is definedherein as a Boolean or numerical literal, or a (recursive) lambdaabstraction).

[0107] As used herein, a transition system describes an interpreter ofthe language through a transition relation which defines the computationof any expression e into a new expression e′, and is noted e→e′. Also,several computation steps such as e→e′→e″ are abbreviated herein usingthe notation e

e″. Normalizing computations will reduce the expression e to a term e′which cannot be further reduced; this particular computation step isnoted e

e′ and formally defined by:$\frac{\left. e\rightarrow{e^{\prime}\quad e^{\prime}} \right.}{\left. e\rightarrow{o\quad e^{\prime}} \right.}\lbrack{norm}\rbrack$

[0108] By convention, values are noted v or n, s if they are numeric orstring constants. A derivation chain that reduces to a value is noted e

v. The notation e

e′ is used herein for derivation paths of zero or more stepstransforming e in e′.

[0109] The following equations define the testing operation semantics:

if true then e₂ else e₃→e₂   [if1]

if false then e₂ else e₃→e₃   [if2] $\begin{matrix}\frac{\left. e_{1}\rightarrow e_{1}^{\prime} \right.}{\left. {{if}\quad e_{1}\quad {then}\quad e_{2}\quad {else}\quad e_{3}}\rightarrow{{if}\quad e_{1}^{\prime}\quad {then}\quad e_{2}\quad {else}\quad e_{3}} \right.} & \left\lbrack {{if}\quad 3} \right\rbrack\end{matrix}$

[0110] The semantics of operations on basic types is without surprisedefined as (where the meta symbol is given by *ε{+,−,*,>,==}, and where^(ε) evaluates numeric literals into integer):$\frac{\left. e_{1}\rightarrow e_{1}^{\prime} \right.}{\left. {e_{1}\bigstar \quad e_{2}}\rightarrow{e_{1}^{\prime}\quad \bigstar \quad e_{2}} \right.}\left\lbrack {{left}{­\bigstar}} \right\rbrack$$\frac{\left. e_{2}\rightarrow e_{2}^{\prime} \right.}{\left. {\upsilon \quad \bigstar \quad e_{2}}\rightarrow{\upsilon \quad \bigstar \quad e_{2}^{\prime}} \right.}\left\lbrack {{right}{­\bigstar}} \right\rbrack$$\frac{{ɛ\left( n_{3} \right)} = {{ɛ\left( n_{1} \right)} + {ɛ\left( n_{2} \right)}}}{\left. {n_{1} + n_{2}}\rightarrow n_{3} \right.}\lbrack{add}\rbrack$s₁ + s₂ → s₁s₂[cat]$\frac{{ɛ\left( n_{3} \right)} = {{ɛ\left( n_{1} \right)} \times {ɛ\left( n_{2} \right)}}}{\left. {n_{1}*n_{2}}\rightarrow n_{3} \right.}\lbrack{mul}\rbrack$$\frac{{ɛ\left( n_{3} \right)} = {{ɛ\left( n_{1} \right)} - {ɛ\left( n_{2} \right)}}}{\left. {n_{1} - n_{2}}\rightarrow n_{3} \right.}\lbrack{sub}\rbrack$

[0111] Note for the definitions [eq] and [neq] below, the symbol“=^(α)”, which is known as alpha-equivalence in the lambda calculustheory, is the syntactic equality, up to alpha-substitution (as setforth at the beginning of section D.2 below). $\begin{matrix}\frac{\upsilon_{1} =^{\alpha}\upsilon_{2}}{\left. {\upsilon_{1}==\upsilon_{2}}\rightarrow{true} \right.} & \lbrack{eq}\rbrack \\{\lbrack{eq}\rbrack \frac{\left( {\upsilon_{1} =^{\alpha}\upsilon_{2}} \right)}{\left. {\upsilon_{1}==\upsilon_{2}}\rightarrow{false} \right.}} & \lbrack{neq}\rbrack \\\frac{{ɛ\left( n_{1} \right)} > {ɛ\left( n_{2} \right)}}{\left. {n_{1} > n_{2}}\rightarrow{true} \right.} & \lbrack{gt}\rbrack \\\frac{{ɛ\left( n_{1} \right)} \leq {ɛ\left( n_{2} \right)}}{\left. {n_{1} > n_{2}}\rightarrow{false} \right.} & \lbrack{ngt}\rbrack\end{matrix}$

[0112] Both lazy and strict application evaluate left argument first:$\frac{\left. e_{1}\rightarrow e_{1}^{\prime} \right.}{\left. {e_{1}\left( e_{2} \right)}\rightarrow{e_{1}^{\prime}\quad \left( e_{2} \right)} \right.}\left\lbrack @_{1} \right\rbrack$$\frac{\left. e_{1}\rightarrow e_{1}^{\prime} \right.}{\left. {e_{1}\left( e_{2} \right)}\rightarrow{e_{1}^{\prime}\quad \left( e_{2} \right)} \right.}\left\lbrack @_{2} \right\rbrack$

[0113] The strict application requires (a) a normalized left term and(b) evaluating the parameter before substitution, while lazy applicationsubstitutes terms directly.$\frac{\left. e_{2}\rightarrow e_{2}^{\prime} \right.}{\left. {\upsilon \left( e_{2} \right)}\rightarrow{\upsilon\left( e_{2}^{\prime}\quad \right)} \right.}\left\lbrack @_{3} \right\rbrack$

 λx:t.e₁(v)→e₁[v/x]  [β₂]

λx:t.e₁

e₂

→e₁[e₂/x]  [β₁]

[0114] Application on recursive abstractions “f” is performed towardstwo substitutions: the rewriting of the recursion variable by therecursive abstraction itself and then the usual substitution of theparameter.

fixf(x:t)=e(v)→e[fixf(x:t)=e/f][v/x]  [β₃]

[0115] As usual in lambda calculi, the substitution operation involvedin [β₁], [β₂] and [β₃] must avoid name capture.

[0116] C. Additional Type System

[0117] Composition operators operate over types. The typing rules setforth below define well typed properties of types. In one embodiment,the type checker 212 includes instructions that determine whether anexpression is well typed using a series of logical operations thatverify whether an expression is weakly sound in accordance with thetyping rules defined herein.

[0118] C.1 Defining Sub-Type Relations

[0119] Accordingly, this section defines sub-type relations (i.e.,subtype properties of types). That is, this section defines how typespropagate during composition. More specifically, this section presents aformal type system including a (reflexive and transitive) subtyperelation t₁

t₂ (which provides t₁ is a subtype of t₂), with basic axioms for alltype t and expression e. The subtype relations [top] and [bot] aredefined as:

[0120] t

τ [top] ⊥

t [bot]

[0121] Typing assertions are noted herein as e: t(i.e., expression e hastype t). A typing environment γ may contain typing assertions overvariables, and is used through the γ

e:t notation, where “

” provides that expression e has type tin environment γ. Typicallyenvironment γ, x:t means that the current environment contains theassertion that variable x has type t. The typing assertion [sub] isdefined as: $\begin{matrix}\frac{\gamma \vartriangleright {e:{{t_{1}\quad t_{1}} \preccurlyeq t}}}{\gamma \vartriangleright {e:t}} & \lbrack{sub}\rbrack\end{matrix}$

[0122] The proposed notations distinguishes between “exact” typing(e::t) and typing by subsumption (e:t). This allows more precise typecontrol, thereby avoiding over generalizing influences due to so calledsubsumption rule (see [sub] above), while preserving the convenience ofsubtyping mechanism. The union type provides a simple way to construct asuper type by aggregating two types.${\frac{\gamma \vartriangleright e :: t}{\gamma \vartriangleright {e:t}}\lbrack{Min}\rbrack}{\frac{t_{1} \preccurlyeq {t\quad t_{2}} \preccurlyeq t}{t_{1}{{t_{2} \preccurlyeq t}}}\left\lbrack {U\quad 1} \right\rbrack}$${\frac{t \preccurlyeq t_{1}}{t \preccurlyeq {t_{1}{t_{2}}}}\left\lbrack {U\quad 2} \right\rbrack}\quad {\frac{t \preccurlyeq t_{2}}{t \preccurlyeq {t_{1}{t_{2}}}}\left\lbrack {U\quad 3} \right\rbrack}$

[0123] The proposed type system makes use of two relations over types.

[0124] Definition 1: Greatest common subtype

.

[0125] Let L be the language generated by the grammar of types, where

is a total mapping from L×L into L such that:

[0126] ∀ t₁, t₂, t₁

t₂ is the greatest common subtype of t₁ and t₂.

[0127] Definition 2: Lowest common supertype

.

[0128] Let L be the language generated by the grammar of types, where

is a relation from L×L into L such that:

[0129] ∀, t₂, t₁

t₂ is the greatest common subtype of t₁ and t₂.

[0130] Note that common subtypes or super types always exist because ofthe definition of τ and ⊥ types. The ⊕ relation (used for instance inthe [If] rule) is more abstract than the type union, since for instanceint ⊕ string is either int|string or int|string|int. The [If] ruleallows therefore precise and flexible typing of conditional statements,and the same for lambda abstractions (i.e., rules [f2,f2b] and[Fix,Fixb]).

[0131] The structural equality allows a natural treatment of types andtheir properties.

[0132] Definition 3: Structural type equality.

t₁=t₂

t

1

t ₂ and t₂

t₁

[0133] C.2 Typing Rules For Defining Well Typed Properties of Terms

[0134] The following set of typing equations covers additional logicalassertions needed to handle the static semantics of the defined calculus(*ε{+,−,*}). (Note that Ø

indicates that no typing context information is necessary.)

φ

true::bool   [b1]

φ

false::bool   [b2]

φ

n::int   [i]

φ

s::string   [s]

γ, x:t

x::t   [var] $\begin{matrix}\frac{t_{3} \preccurlyeq {t_{1}\quad t_{2}} \preccurlyeq t_{4}}{\left. t_{1}\rightarrow\left. {t_{2} \preccurlyeq t_{3}}\rightarrow t_{4} \right. \right.} & \lbrack{fsub}\rbrack \\\frac{t_{3} \preccurlyeq {t_{1}\quad t_{2}} \preccurlyeq t_{4}}{\left. t_{1}\rightarrow\left. {t_{2} \preccurlyeq t_{3}}\rightarrow t_{4} \right. \right.} & \lbrack{fsub2}\rbrack \\\frac{\gamma \vartriangleright {e_{1}:{{{bool}\quad \gamma} \vartriangleright e_{2} :: {t_{1}\quad \gamma} \vartriangleright e_{3} :: t_{2}}}}{\gamma \vartriangleright {{if}\quad e_{1}\quad {then}\quad e_{2}\quad {else}\quad e_{3}} :: {t_{1} \oplus t_{2}}} & \lbrack{If}\rbrack \\\frac{\gamma \vartriangleright {e_{1}:{{{string}\quad \gamma} \vartriangleright {e_{2}:{string}}}}}{\gamma \vartriangleright {e_{1} + e_{2}} :: {string}} & \left\lbrack {s - +} \right\rbrack \\\frac{\gamma \vartriangleright {e_{1}:{{{int}\quad \gamma} \vartriangleright {e_{2}:{int}}}}}{\gamma \vartriangleright {e_{1}\bigstar \quad e_{2}} :: {int}} & \lbrack{i­\bigstar}\rbrack \\\frac{\gamma \vartriangleright {e_{1}:{\top\quad {\gamma \vartriangleright {e_{2}:\top}}}}}{\gamma \vartriangleright e_{1}==e_{2} :: {bool}} & \lbrack{t­eq}\rbrack \\\frac{\gamma \vartriangleright {e_{1}:{{{int}\quad \gamma} \vartriangleright {e_{2}:{int}}}}}{\gamma \vartriangleright e_{1} > e_{2} :: {bool}} & \lbrack{t­gt}\rbrack\end{matrix}$

[0135] The typing of abstraction and application can be classicallyhandled through the following equations. (Note also that the meta symbol

in [a] ranges over symbols → and

.) $\begin{matrix}\frac{{x \notin {{{dom}(\gamma)}\quad \gamma}},{x:{t_{1} \vartriangleright e :: t_{2}}}}{\gamma \vartriangleright {\lambda \quad {x:\left. {{t_{1} \cdot e} :: t_{1}}\rightarrow t_{2} \right.}}} & \lbrack f\rbrack \\\frac{f,{x \notin {{{dom}(\gamma)}\quad \gamma}},{x:t_{1}},{f:{{t_{1}t_{2}} \vartriangleright e :: t_{2}}}}{{\gamma \vartriangleright {{fix}{\quad \quad}{f\left( {x:t_{1}} \right)}}} = {e :: {t_{1}t_{2}}}} & \lbrack{Fix}\rbrack \\\frac{\left. {\gamma \vartriangleright e_{1} :: t_{1}}\rightarrow{{t_{2}\quad \gamma} \vartriangleright {e_{2}:t_{1}}} \right.}{\gamma \vartriangleright {e_{1}\left( e_{2} \right)} :: t_{2}} & \lbrack a\rbrack \\\frac{\left. {\gamma \vartriangleright e_{1} :: t_{1}}\rightarrow{{t_{2}\quad \gamma} \vartriangleright {e_{2}:t_{1}}} \right.}{\gamma \vartriangleright {e_{1}\left( e_{2} \right)} :: t_{2}} & \lbrack{a2}\rbrack\end{matrix}$

[0136] The precise typing of some functional abstraction A

λ x:int|string.x+x is not possible through this conventional approach,although it is correct from the execution point of view. This expressionis defined herein as type int|string→int|string since A(10)

20 and A(‘10’)

‘1010’. In addition, the following is asserted as well A(10):int andA(‘10’):string. The following sets of equations provide more typingpower both for non-recursive and recursive abstractions (where in theequation [Fix⁺]t_(ij) ε{t₁, . . . , t_(n)} and all distinct, and in theequation [a⁺]i₁, . . . , i_(k) ε[1,n] and all distinct). $\begin{matrix}\frac{{x \notin {{{dom}(\gamma)}\quad \gamma}},{x:{t_{1} \vartriangleright e :: {t_{1}^{\prime}\quad \cdots \quad \gamma}}},{x:{t_{n} \vartriangleright e :: e_{N}^{\prime}}}}{\gamma \vartriangleright {\lambda \quad {x:{{t_{1}{\cdots }{t_{n} \cdot e}} :: {\left( t_{1}\rightarrow t_{1}^{\prime} \right) \oplus \cdots \oplus \left( t_{n}\rightarrow t_{n}^{\prime} \right) \oplus \left( {t_{1}{\cdots }t_{n}}\rightarrow{t_{1}^{\prime}{\cdots }t_{n}^{\prime}} \right)}}}}} & \left\lbrack f^{+} \right\rbrack \\\frac{\left( {{E\left( {e_{1}\left\lbrack {z/x_{1}} \right\rbrack} \right)}{\cdots \left( {e_{i}\left\lbrack {{F/f_{i}},{z/x_{i}}} \right\rbrack} \right)}\quad \cdots \quad \left( {e_{n}\left\lbrack {z/x_{n}} \right\rbrack} \right)e} \right)}{\left( {\left. {{\quad}_{E}^{\oplus}\left( {{\lambda \quad {x_{1}:{t_{1} \cdot e_{1}}}},\ldots \quad,{{{fix}\quad {f_{i}\left( \quad {x_{i}:t_{i}} \right)}} = e_{i}},\ldots \quad,{\lambda \quad {x_{n}:{t_{n} \cdot e_{n}}}}} \right)}\rightarrow{{fix}\quad F\quad \left( \quad {z:t^{x}} \right)} \right. = e} \right)} & \left\lbrack {Fix}^{+} \right\rbrack \\\frac{\left. {\gamma \vartriangleright e_{1} :: t_{1}}\rightarrow\left. {t_{1}^{\prime}{\cdots }\quad t_{n}}\rightarrow{t_{n}^{\prime}\quad \left\{ \begin{matrix}{\gamma \vartriangleright {e_{2}:{{t_{11}\quad \cdots \quad \gamma} \vartriangleright {e_{2}:t_{1k}}}}} & {t_{11} \preccurlyeq \cdots \preccurlyeq t_{1k}} \\\vdots & \vdots \\{\gamma \vartriangleright {e_{2}:{{t_{j\quad 1}\quad \cdots \quad \gamma} \vartriangleright {e_{2}:t_{jm}}}}} & {t_{11} \preccurlyeq \cdots \preccurlyeq t_{1k}}\end{matrix}\quad \right.} \right. \right.}{\gamma \vartriangleright {e_{1}\left( e_{2} \right)} :: {t_{11}^{\prime} \oplus \quad \cdots \quad \oplus t_{j\quad 1}^{\prime}}} & \left\lbrack a^{+} \right\rbrack \\\frac{\left. {\gamma \vartriangleright e_{1} :: t_{1}}\rightarrow\left. {t_{2}{\cdots }t_{n}}\rightarrow{{t_{n}^{\prime}\quad \gamma} \vartriangleright {e_{2}:{{t_{i\quad 1}\quad \cdots \quad \gamma} \vartriangleright {e_{2}:t_{ik}}}}} \right. \right.}{\gamma \vartriangleright {e_{1}\left( e_{2} \right)} :: {t_{i\quad 1}^{\prime} \oplus \quad \cdots \quad \oplus t_{ik}^{\prime}}} & \left\lbrack {a2}^{+} \right\rbrack\end{matrix}$

[0137] D. The Composition Of Functional Abstractions

[0138] The composition of abstractions specified in this section areperformed through: an n-ary (parametric) operator that follows thesyntax

_(E)(e₁, . . . , e_(n)), where E is a lambda term that parameterizes theoperation; and one unary operator

(e). The semantics of the first composition is defined by the followingthree rules [c0], [c1], and [c2]: e i → e i ′ E  ( v 1 , …    , e i ,…    , e n ) → E  ( v 1 , …    , e i ′ , …    , e n ) [ c0 ]

[0139] Rule [c0] shows that each operand is normalized, following a leftto right order. The next rule [c1] shows how the operator reduces to itsterminal form when all operands are normalized to lambda abstractions asfollows: ( z     fresh )  E  ( e 1  [ z / x 1 ] )  ⋯  ( e n  [ z/ x n ] )    e E  ( λ     x 1 : t · e 1 , …    , λ     x n : t· e n ) → λ     z : t · e [ c1 ]

[0140] The composition of (at least) one recursive lambda abstractionproduces a recursive lambda abstraction reduced to its terminal form asfollows in rule [c2]: ( F , z     fresh )  E  ( e 1  [ z / x 1 ] ) ⋯  ( e n  [ F / f i , z / x i ] )     ⋯     ( e n  [ z / x n ])    e E  ( λ     x 1 : t · e 1 , …    , fix     f i (    x i: t ) = e i , …    , λ     x n : t · e n ) → fix        F     (   z : t ) = e [ c2 ]

[0141] The semantics of the second operator are defined by the followingtwo rules [c3a] and [c3]: $\begin{matrix}\frac{\left. e\rightarrow e^{\prime} \right.}{\left. {(e)}\rightarrow{\left( e^{\prime} \right)} \right.} & \lbrack{c3a}\rbrack\end{matrix}$

 (f fresh)

(λx:t.e)→fixf(x:t)=f(e)   [c3]

[0142] D.1 Typing of Composition Operators

[0143] The composition operators are typed as follows (note that in thisand other typing sections the symbol “→” means returns, where in othersections not concerning typing, it means transforms): i ∈ [ 1 , n ]  γ⊳ E ∷ t 1 ′ → ⋯ → t n ′ → t 2     γ ⊳ e i : t 1 → t i ′ γ ⊳ E  ( e 1, …    , e n ) ∷ t 1 → t 2 [ C  -  1 ]

[0144] For all i, j ε[1,n], i≠j: γ ⊳ E ∷ t 1 ′ → ⋯ → t n ′ → t 2     γ⊳ e i ∷ t 1 → t i ′     γ ⊳ e j : t 1   t j ′ γ ⊳ E  ( e 1 , …   , e n ) ∷ t 1   t 2 [ C  -  2 ]

$\begin{matrix}\frac{\left. {\gamma \vartriangleright e :: t_{1}}\rightarrow t_{2} \right.}{\gamma \vartriangleright {(e)} :: {t_{1}t_{2}}} & \lbrack F\rbrack\end{matrix}$

[0145] D.2 Computational Equivalence

[0146] This section defines an equivalence over terms of the calculusdefined herein, noted “˜”, up to α-equivalence “=^(α)” (i.e., two termsare α-equivalent if there exists a substitution which brings the termsto syntactic equality).

[0147] Definition 4: Computational Equivalence “˜” is given by:

e ₁ ˜e ₂ iff e ₁

v ₁ and v ₁=^(α) v ₂

[0148] It may be shown that “˜” is an equivalence relation, i.e.,reflexive, symmetric and transitive (assuming that “=^(a)” is anequivalence relation also).

[0149] D.3 Application to the Computation of Numeric Series

[0150] This section provides examples of the application of compositionoperators to the computation of numeric series. Consider the recursivefunction “Fact” which computes the factorial product of any positiveinteger “x” as follows:

Fact

fixf (x:int)=if x>1 then x*f(x−1)else x

[0151] Applied to 4, “Fact” returns 4!=4×3×2×1 (i.e., Fact (4)

24). In addition, consider the following functions “S” and “Fibo” (whichcomputes the Fibonacci number of rank “x”):

S

fixf(x:int)=if x>1 then x+f(x−1) else x

Fibo

fixf(x:int)=if x>1 then f(x−2)+f(x−1) else x

[0152] Considering now the function “S” which applied to 4 returns4+3+2+1 (i.e., S(4)

10), it can be observed there exists a strong similarity between thestructure of the code for the functions “Fact” and “S”. In addition, asimilar structure for the code can be observed between the functions“Fact” and “Fibo”.

[0153] The composition operators defined herein are advantageouslyadapted to capture “patterns” in the example functions (e.g., Fact, S,and Fibo) as the composition of fewer fundamental lambda abstractions,some of which are reused several times in order to build the following˜-equivalent abstractions: Id

λx:int.x Add

λx:int.λy:int.x + y Sub

λx:int.λy:int.x − y Mul

λx:int.λy:int.x * y If

λx:int.λy:int.if x > 1 then y else x

[0154] Proposition 1: Is given by: let A

_(Sub)(Id, λx:int.1) then A ˜ λx:int.x − 1 let B

_(Sub)(Id, λx:int.2) then B ˜ λx:int.x − 2

[0155] Proving proposition 1 is a straightforward application of [c1] onA and B (defined above) that result in a lambda term which cannot befurther reduced and is an α-equivalent to “λ x:int.x−1”.

[0156] Proposition 2: Is given by:

_(If)(Id,

_(Mul)(Id,

(A))) ˜ Fact

_(If)(Id,

_(Add)(Id,

(A))) ˜ S

_(If)(Id,

_(Add)(

(B),

(A))) ˜ Fibo

[0157] In proving proposition 2, a derivation path is produced for thefunction “Fact” as follows:

_(If)(Id,

_(Mul)(Id,

(A)))

_(If)(Id,

_(Mul)(Id,fixF(z:int)=F(z − 1)))

_(If)(Id,fixF(z′:int)=z′ * F(z′ − 1))

fixF′(z″:int)=if z″ > 1 then z″ * F′(z″ − 1) else z″

[0158] where a, b, and c correspond to:

[0159]^(a)c0.c0.c3

[0160]^(b)c0, c2, @₂, β₁, β₁

[0161]^(c)c2, @₂, β₁, β₁

[0162] Proposition 3 (which provides that during composition basicbuilding blocks can be reused) is given by: let Z

λa:int → int → int.λb:int → int

_(If)(Id,

_(a)(b,

(A))) Z(Mul)(Id) ˜ Fact then {open oversize brace} Z(Add)(Id) ˜ SZ(Add)(

(B)) ˜ Fibo

[0163] It will be appreciated that the obtained reuse is “syntactic” ,as opposed to the functional reuse which is related to runtimefactorization of program instructions. As a consequence, the result ofthe composition will execute as fast as the original abstraction (e.g.,Fact). However, standard functional composition will not benefit fromsimilar efficiencies, with patterns such as:

fixf(x:int)=if x>1 then Mul(x)(f(Sub(x)(1))) else x

[0164] or with more abstract patterns such as:

W

λf:int→int→int.λg:int→int→int.fixF(x:int)=if x>1 then f(x)(F(g(x)(1)))else x

[0165] which allows equivalent computation after installation of:

W(Mul)(Sub)(4)˜Fact(4)and W(Add)(Sub)(4)˜S(4)

[0166] In terms of computation costs, if W(Mul)(Sub)

w and Z(Mul)(Id)

z then w(n) computes n! through “8×(n−1)+1” steps versus “4×(n−1)+1” forz(n).

[0167] D.4 Handling Subtype Polymorphism (Generalization)

[0168] The definitions above for [c1] and [c2] require all parameters offunctional abstractions to share the same type. This, however, is alittle too restrictive. It would therefore be better for instance to usethe definition “I

λ x:T.x” rather than the earlier definition “λ x:int.x”, since the firstdefinition is a more general identity function. However, correct typingfor the composition needs to be ensured. For example, the expression:

_(Mul)(I, λx:int.x−1)

[0169] cannot be typed (i.e., Mul:int→int→int does not yield T

int). Accordingly, the following polymorphic variants for [c1], [c2],[C−1], [C−2] (i ε[1,n], t^(×)=t₁

. . .

t_(n) and t⁺=t₁ ⊕ . . . ⊕ t_(n)) are given by: $\begin{matrix}{\left( {z\quad {fresh}} \right)\frac{{E\left( {e_{1}\left\lbrack {z/x_{1}} \right\rbrack} \right)}{\cdots \left( {e_{n}\left\lbrack {z/x_{n}} \right\rbrack} \right)}e}{{\quad}_{E}^{\oplus}\left. \left( {{\lambda \quad {x_{1}:{t_{1} \cdot e_{1}}}},\ldots \quad,{\lambda \quad {x_{n}:{t_{n} \cdot e_{n}}}}} \right)\rightarrow{\lambda \quad {z:{t^{x} \cdot e}}} \right.}} & \lbrack{c1}\rbrack \\{\left( {F,{z\quad {fresh}}} \right)\frac{\left( {{E\left( {e_{1}\left\lbrack {z/x_{1}} \right\rbrack} \right)}{\cdots \left( {e_{i}\left\lbrack {{F/f_{i}},{z/x_{i}}} \right\rbrack} \right)}\quad \cdots \quad \left( {e_{n}\left\lbrack {z/x_{n}} \right\rbrack} \right)e} \right)}{\left( {\left. {{\quad}_{E}^{\oplus}\left( {{\lambda \quad {x_{1}:{t_{1} \cdot e_{1}}}},\ldots \quad,{{{fix}\quad {f_{i}\left( \quad {x_{i}:t_{i}} \right)}} = e_{i}},\ldots \quad,{\lambda \quad {x_{n}:{t_{n} \cdot e_{n}}}}} \right)}\rightarrow{{fix}\quad F\quad \left( \quad {z:t^{x}} \right)} \right. = e} \right)}} & \lbrack{c2}\rbrack \\\frac{\left. {\gamma \vartriangleright E :: t_{1}^{\prime}}\rightarrow\left. \cdots\rightarrow\left. t_{n}^{\prime}\rightarrow{{t_{2}\quad \gamma} \vartriangleright {e_{i}:\left. t^{x}\rightarrow t_{2} \right.}} \right. \right. \right.}{\left. {{{\gamma( \vartriangleright \quad)}_{E}^{\oplus}\left( {e_{1},\ldots \quad,e_{n}} \right)} :: t^{x}}\rightarrow t_{2} \right.} & \left\lbrack {C\text{-}1a} \right\rbrack \\\frac{\left. {\gamma \vartriangleright E :: t_{1}^{\prime}}\rightarrow\left. \cdots\rightarrow\left. t_{n}^{\prime}\rightarrow{{t_{2}\quad e_{i}}\overset{*}{\rightarrow}{\lambda \quad {x:{{t \cdot e_{i}^{\prime}}\quad \varnothing}}}} \right. \right. \right.,{e:{t^{\oplus} \vartriangleright {e_{i}^{\prime}:t_{i}^{\prime}}}}}{{{\gamma( \vartriangleright \quad)}_{E}^{\oplus}\left( {e_{1},\ldots \quad,e_{n}} \right)} :: {t^{\oplus}t_{2}}} & \left\lbrack {C\text{-}1b} \right\rbrack \\{{j \in \left\lbrack {1,n} \right\rbrack},{j \neq {i\frac{\begin{matrix}\left. {\gamma \vartriangleright E :: t_{1}^{\prime}}\rightarrow\left. \cdots\rightarrow\left. t_{n}^{\prime}\rightarrow t_{2} \right. \right. \right. \\{{e_{i}\overset{*}{\rightarrow}{\lambda \quad {x:{{t \cdot e_{i}^{\prime}}\quad \varnothing}}}},{e:{t^{x} \vartriangleright {e_{i}^{\prime}:t_{i}^{\prime}}}}} \\{{{e_{j}\overset{*}{\rightarrow}{{fix}\quad {f\left( \quad {x:t} \right)}}} = {e_{j}^{\prime}\quad \varnothing}},{x:t^{x}},{f:{{t^{x}t_{j}^{\prime}} \vartriangleright {e_{j}^{\prime}:t_{j}^{\prime}}}}}\end{matrix}}{{{\gamma( \vartriangleright \quad)}_{E}^{\oplus}\left( {e_{1},\ldots \quad,e_{n}} \right)} :: {t^{x}t_{2}}}}}} & \left\lbrack {C\text{-}2a} \right\rbrack\end{matrix}$

[0170] E. Extending The Calculus With Imperative Expressions

[0171] E.7 Computing Environment

[0172] The computing environment, which is noted herein as S, is a stackof mappings from names (of variables) to reduced values, such that:

S::={x _(i) ^(v) }|S,{x _(i) ^(v)}

[0173] with x_(i) ^(v) defining a notation for the mapping of a uniquelabel x_(i) into a reduced value v_(j), and where “^(S),x^(v)” is oftenan abbreviation for “^(S),s ∪ {x^(v)}”.

[0174] The transition relation now becomes S ├ e→S′ ├ e′ in the generalcase, although invariant execution structures can be skipped for claritywhen required. Informally, this relation means “expression e computed inenvironment S becomes e′ in environment S′”, while understanding that S′is possibly different from S. In this new environment, previouscomputation e→e′ must be understood as ∪ ├ e→Ø ├ e′, and previous rulescomprising relations like e→e′ must be understood as S ├ e→S′ ├ e′.

[0175] E.2 Syntactic Extensions

[0176] Syntactic extensions mainly introduce variable declarations,imperative control statements and procedural abstractions. Twodistinguished values unit, none together with their associated typesUnit, None play an important role in defining (and typing) proceduralcomposition. Note also that the ∇-abstraction (also called “pam” for“polymorphic abstract machine”) and its recursive variant have distincttypes (similar to λ-abstractions). e ::= var x = e.e variabledeclaration x := e | * (e) | e;e | eassignrnent, iterarion, sequencing e

e | [|e₁,...,e_(n)|] rule, action systems unit | none | pop x | specialconstants, internal op ∇x:t,y:t.e | ∇ procedural abstractionfixF(x:t,y:t)=e ∇ fix point abstraction t ::= Unit | None | t

t | t

t Unit and None type, pam, recursive pam

[0177] Note that “pop x” is intended to be an internal term used fordefining the semantics of nabla application (as generated by theinterpreter) (see [@-∇, @-∇-F]), not explicitly available for specifyingcomputation.

[0178] E.3 Operational Semantics

[0179] The following equations describe the semantics of variable access([var]), pop operation ([pop]), and declarations ([d1], [d2]):

S,x^(v) ├ x→S,x^(v) ├ v   [var]

S,s ∪ {x^(v)} ├ pop x→S ├ v   [pop]

S ├ e ₁ →S′ ├ e ₁ ′/S ├ var x=e ₁ .e ₂ →S′ ├ var x=e ₁ ′.e ₂   d1]

S,s ├ var x=v.e→S,s ∪ {x ^(v) } ├ e   [d2]

[0180] Assignment allows changing the value referenced by a variable asfollows: $\begin{matrix}\frac{S \vdash \left. \rightarrow S^{\prime} \right. \vdash ^{\prime}}{{S \vdash x}:={{\left. \rightarrow S^{\prime} \right. \vdash x}:=^{\prime}}} & \left\lbrack {v - {assg}} \right\rbrack\end{matrix}$

S,x ^(w) ├x:=v→S,x ^(v) ├ unit   [v-assg]

[0181] Iteration of a statement relies on a Boolean invariant: thestatement evaluates to a unit. A rule which cannot be applied evaluatesto none.

*(e)→if e==unit then *(e) else unit   [iter]

e ₁

e ₂→if e ₁==true then e _(2 else none)   [rule]

[0182] An action system is an ordered collection of statements.Statement i+1 is executed only if statement “i” evaluates to none.$\begin{matrix}{{\upsilon_{f}\quad {fresh}},\left. {n \geq {2\quad\left\lbrack {{e_{1},\ldots \quad,e_{n}}} \right\rbrack}}\rightarrow\left\lbrack \begin{matrix}{{{{var}\quad \upsilon_{f}} = {e_{1}.}}\quad} \\{{{if}\quad \left( {\upsilon_{f}{none}} \right)}\quad} \\{{then}\quad\left\lbrack {{e_{2},\ldots \quad,e_{n}}} \right\rbrack} \\{{{else}\quad \upsilon_{f}}\quad}\end{matrix}\quad \right. \right.} & \lbrack{AsysI}\rbrack\end{matrix}$

 [|e|]→e   [Asys2]

[0183] A sequence of statement evaluates first its left argument.$\begin{matrix}\frac{S \vdash \left. e_{1}\rightarrow S^{\prime} \right. \vdash e_{1}^{\prime}}{{S \vdash e_{1}};{\left. e_{2}\rightarrow S^{\prime} \right. \vdash e_{1}^{\prime}};e_{2}} & \lbrack{seq1}\rbrack\end{matrix}$

 v;e₂→e  seq2]

[0184] Application on procedural abstractions creates a new store on topof the stack of mappings in the computing environment S. This storecontains the input value and the output is initialized through a defaultvalue computed by init(t) from the type “t”. The result (i.e., the valueof the output parameter after completion of the computation) is returnedthrough the following pop instruction:

t ₂ ≠⊥ S ├ ∇x:t ₁ ,y:t ₂ .e(v)→S,{x ^(v) , y ^(init(t) ^(₂) ⁾ {├ e; popy   [@-∇]

[0185] The application on recursive procedural abstractions “f”similarly creates a new store on top of the stack that contains areference to “f” itself as follows:

t ₂ ≠⊥ S ├ fixf(x:t ₁ , y:t ₂)=e(v)→S, {f ^(fix f(xt) ^(₁) ^(, yt) ^(₂)^()=e) , x ^(v) , y ^(init(t) ^(₂) ⁾ } ├ e; pop y   @-∇-F]

[0186] E.4 Type System

[0187] Additions to the type system set forth in section C include thefollowing equations:

γ

unit::Unit   [Unit]

γ

none::None   [None] $\begin{matrix}{\frac{\gamma \vartriangleright x :: t}{\gamma \vartriangleright {popx} :: t}{x \notin {{dom}(\gamma)}}} & \lbrack{Pop}\rbrack \\\frac{{\gamma \vartriangleright {e_{1}\text{:}t\quad \gamma}},{{\overset{\_}{x}\text{:}t} \vartriangleright e_{2} :: t^{\prime}}}{{\gamma \vartriangleright {{var}\quad x}} = {{e_{1} \cdot e_{2}} :: t^{\prime}}} & \lbrack{Dec1}\rbrack \\\frac{\gamma \vartriangleright {e\text{:}t}}{\gamma,{{{\overset{\_}{x}\text{:}t} \vartriangleright x}:={ :: {Unit}}}} & \lbrack{Assg}\rbrack \\\frac{{{\gamma \vartriangleright  :: {Unit}}}{None}}{\gamma \vartriangleright {*()} :: {Unit}} & \lbrack{Iter}\rbrack \\\frac{{{{\gamma \vartriangleright {e_{1}\text{:}{Unit}}}}{None}\quad \gamma} \vartriangleright e_{2} :: t_{2}}{{\gamma \vartriangleright e_{1}};{e_{2} :: t_{2}}} & \lbrack{Seq}\rbrack\end{matrix}$

[0188] As set forth in the equation [Dec1] above, a variable name “x”isintroduced into the environment with the notation “{overscore (x)}”.This is required in order to distinguish variable names from lambdaparameters. With a parameter such as “y”, an operation such as “y:=e”isnot well typed since the equation [Assg] requires a variable name. Inthe declaration [T-∇, T-∇-F], input and output parameters are introducedas variables into the environment so that they can be modified whenembedded code is executed.

[0189] In the following two equations, “α” makes explicit the type ofthe code embedded into the abstraction. This is not used in the subtyperelation (see [∇-sub1, ∇-sub2]), but in the composition operationsdefined later. $\begin{matrix}{t_{2} \neq \bot\frac{\begin{matrix}{x,{y \notin {{dom}\quad (\gamma)\quad \gamma}},{\overset{\_}{x}\text{:}t_{1}},} \\{{{{\overset{\_}{y}\text{:}t_{2}} \vartriangleright e :: {\alpha \quad \gamma} \vartriangleright \alpha \preccurlyeq {Unit}}}{None}}\end{matrix}}{{\gamma \vartriangleright {{\nabla x}\text{:}t_{1}y\text{:}{t_{2}.e}} :: t_{1}}\overset{\alpha}{\Rightarrow}t_{2}}} & \left\lbrack {T\text{-}\nabla} \right\rbrack \\{t_{2} \neq \bot\frac{\begin{matrix}{x,y,{f \notin {{{dom}(\gamma)}\quad \gamma}},{\overset{\_}{f}\text{:}t_{1}{{\overset{\alpha}{\Rightarrow}t_{2}}}}} \\{{{{\overset{\_}{x}\text{:}t_{1}},{{\overset{\_}{y}\text{:}t_{2}} \vartriangleright e :: {\alpha \quad \gamma} \vartriangleright \alpha \preccurlyeq {Unit}}}}{None}}\end{matrix}}{{\gamma {{{fix}f}\left( {{x\text{:}t_{1}},{y\text{:}t_{2}}} \right)}} = {e :: {t_{1}{{\overset{\alpha}{\Rightarrow}t_{2}}}}}}} & \left\lbrack {T\text{-}{\nabla\text{-}}F} \right\rbrack \\\frac{\gamma \vartriangleright t_{2} \preccurlyeq {t_{4}\quad \gamma} \vartriangleright t_{3} \preccurlyeq t_{1}}{{\gamma \vartriangleright t_{1}}\overset{\alpha}{\Rightarrow}{t_{2} \preccurlyeq t_{3}}\overset{\alpha^{\prime}}{\Rightarrow}t_{4}} & \left\lbrack {{\nabla\text{-}}{sub1}} \right\rbrack \\\frac{\gamma \vartriangleright t_{2} \preccurlyeq {t_{4}\quad \gamma} \vartriangleright t_{3} \preccurlyeq t_{1}}{\gamma \vartriangleright {t_{1}{{\overset{\alpha}{\Rightarrow}{t_{2} \preccurlyeq {t_{3}{{\overset{\alpha^{\prime}}{\Rightarrow}t_{4}}}}}}}}} & \left\lbrack {{\nabla\text{-}}{sub2}} \right\rbrack \\\frac{\gamma \vartriangleright {e_{1}\text{:}{bool}\quad \gamma} \vartriangleright e_{2} :: t}{\left. {\gamma \vartriangleright e_{1}}\Rightarrow{e_{2} :: {t \oplus {None}}} \right.} & \lbrack{Rule}\rbrack \\\frac{\begin{matrix}{\gamma \vartriangleright e_{1} :: {t_{1} \oplus {{None}\quad \ldots \quad \gamma}} \vartriangleright e_{n - 1} :: {t_{n - 1} \oplus {None}}} \\{\gamma \vartriangleright e_{n} :: t_{n}}\end{matrix}}{\gamma \vartriangleright \left\lbrack {{e_{1},\ldots \quad,e_{n}}} \right\rbrack :: {t_{1} \oplus \quad \ldots \quad \oplus t_{n}}} & \lbrack{Asys}\rbrack\end{matrix}$

[0190] F. Polymorphic Composition Of ∇-Abstractions

[0191] In this section, the meta-variables *, ⋄ range over {(⊕,

}. A parametric function Φ performs a syntactic transformation of “n”terms into a new term.

[0192] F.1 Semantics

[0193] Defining the composition operator: Φ E  ( e 1  [ x / x 1 , y /y 1 ] , ⋯    , e n  [ x / x n , y / y n ] )    E ★ , ⋄  ( ∇ x 1 :  t 1 , y 1  :  t 1 ′ · e 1 , ⋯    , ∇ x n  :  t n , y n  :  tn ′ · e n ) -> ∇ x  :  t 1  ★     ⋯     ★t n , y  :  t 1 ′ ⋄   ⋯    ⋄ t n ′ · e n [ c4 ]

[0194] More precisely, Φ_(E) kinitially performs a recursive decentwhile it encounters variable declarations (the last variabledeclarations are not ignored but consistently renamed in order to avoidname clashes) and then applies “E” to the first term found. The Φfunction over terms is formally defined by ({overscore (e)} is anotation for any term “e” which does not have the syntactic form var

x=e₁.e₂):

Φ_(E)(var x ₁ =e ₁ .e ₁ ′, . . . e _(n))=var x _(f) =e ₁.Φ_(E)(e ₁ ′[x_(f) /x ₁ ], . . . e _(n)) (x _(f) fresh)

Φ_(E)({overscore (e₁)} , . . . e _(n))=

E

{overscore (e₁)}

Φ_(E))e ₂ , . . . e _(n)) Φ E ( e 1  [ x / x 1 , y / y 1 ] , ⋯    , ei  [ F / f i , x / x i , y / y i ] , ⋯    , e n  [ x / x n , y / y n] )    E ★ , ⋄  ( ∇ x 1  :  t 1 , y 1  :  t 1 ′ · e 1 , ⋯    ,fix        f i  ( x i  :  t i , y i  :  t i ) = e i , ⋯    , ∇x n  :  t n , y n  :  t n ′ · e n ) -> fix     F ( x  :  t ★ , y :  t ′ ⋄ ) =  [ c5 ] t 1 ′  ★t 2 ≠ ⊥ Φ E  ( e 1  [ x / y 1 ] , e2  [ x / x 2 ] )     ( ∇    x 1  :  t 1 , y 1  :  t 1 ′ · e 1, ∇    x 2  :  t 2 , y 2  :  t 2 ′ · e 2 ) -> ∇    x 1  :  t 1 ,y 2  :  t 2 ′ · var     x = init  ( t 1 ′  ★t 2 ) · e [ c6 ]

[0195] and with:

Iter

λx:Unit|None.*(x) $\begin{matrix}\frac{{\Phi_{Iter}(e)}e^{\prime}}{{{\left( {{{\nabla x}\text{:}t},{y\text{:}{t^{\prime} \cdot }}} \right)}->{{\nabla x}\text{:}t}},{y\text{:}{t^{\prime} \cdot ^{\prime}}}} & \lbrack{c7}\rbrack \\\frac{{\Phi_{Iter}(e)}e^{\prime}}{{{\left( {{{fix}\quad {f\left( {{x\text{:}t},{y\text{:}t^{\prime}}} \right)}} = } \right)}->{{fix}\quad {f\left( {{x\text{:}t},{y\text{:}t^{\prime}}} \right)}}} = ^{\prime}} & \lbrack{c8}\rbrack \\{\overset{\_}{{{\left( {{{\nabla x}\text{:}t},{y\text{:}{t^{\prime} \cdot }}} \right)}->{{\nabla y}\text{:}t^{\prime}}},{x\text{:}{t \cdot }}}\quad} & \lbrack{c9}\rbrack \\{\overset{\_}{{{\left( {{{fix}\quad {f\left( {{x\text{:}t},{y\text{:}t^{\prime}}} \right)}} = } \right)}->{{fix}\quad {f\left( {{y\text{:}t^{\prime}},{x\text{:}t}} \right)}}} = }} & \lbrack{c10}\rbrack\end{matrix}$

[0196] F.2 Typing

[0197] In accordance with the meta symbols:

[0198] *, ⋄ ε {⊕,

}; i,j ε [1, n], i≠j, and t*=t ₁ * . . . *t _(n) , t′⋄=t ₁ ′⋄ . . . t_(n)′ t ′ ⋄ ≠ ⊥ γ ⊳ E ∷ α 1 -> ⋯ -> α n -> α e i  -> *  ∇ x  :  t i, y  :  t i ′ · e i ′     γ , x _  :  t ★ , y _  :  t ′ ⋄ ⊳ e i′ ∷ α i γ ⊳ E ★ , ⋄  ( e 1 , ⋯    , e n ) ∷ t ★   α  t ′ ⋄ [ C - ∇] t ′ ⋄ ≠ ⊥ γ ⊳ E ∷ α 1 -> ⋯ -> α n -> α e i  -> *  ∇ x  :  t i , y :  t i ′ · e i ′     γ , x _  :  t ★ , y _  :  t ′ ⋄ ⊳ e i ′ ∷α i e j  -> *  fix     f j  ( x  :  t j , y  :  t j ′ ) = e j ′    γ , x _  :  t ★ , y _  :  t ′ ⋄ , f _ j  :  t ★   t ′ ⋄ ⊳e j ′ ∷ α j γ ⊳ E ★ , ⋄  ( e 1 , ⋯    , e n ) ∷ t ★   t ′ ⋄ [ C -∇ - F ] t ′ ⋄ ≠ ⊥ ( γ ⊳ E ∷ α 1 -> α 2 -> α e i  -> *  ∇ x 1  :  t 1, y 1  :  t 1 ′ · e 1 ′ γ , x _ 1  :  t 1 , y _ 1  :  t 1 ′  ★t 2⊳ e 1 ′ ∷ α 1 e 2  -> *  ∇ x 2  :  t 2 , y 2  :  t 2 ′ · e 2 ′ γ ,x _ 2  :  t 1 , ★t 2 , y _ 2  :  t 2 ⊳ e 2 ′ ∷ α 2 ) ( γ ⊳  ( e 1 ,e 2 ) ∷ t 1   α  t 2 ′ ) [ Pipe ] γ ⊳  ∷ t   Unit   None  t ′ γ⊳  (  ) ∷ t   Unit  t ′ [ Iter ] γ ⊳  ∷ t  Unit   None  t ′ γ⊳  (  ) ∷ t  Unit  t ′ [ Iter - F ] t ′ ≠ ⊥ γ ⊳  ∷ t ′   α  t γ⊳  (  ) ∷ t   α  t ′ [ Swap ] γ ⊳  ∷ t ′   t     t = t ′ γ ⊳ (  ) ∷ t   t ′ [ Swap - F ]

[0199] G. A Set Of Composition Operators

[0200] The following table defines different combinations of compositionoperators. It will be appreciated that while this set has particularefficiencies, other combinations are equally possible. Note that theconcurrent execution operator “∥” defined in the table below isdisclosed in U.S. patent application Ser. No. 10/046,191, entitled“Bi-Valuation Of Programming Statements”, which is incorporated hereinby reference. In the table, the column with the heading “definition ofE” defines the composition pattern of the composition operator definedin the column with the heading “operator”. Circus definition syntax E ofE(U N = Unit|None) operator e₁ Then e₂ Then λx:U N.λy:U N.if x ==

(e₁, e₂) unit then y else none e₁ Else e₂ Else λx:U N.λy:U N.if x ==

(e₁, e₂) none then y else unit e₁ Before e₂ Before λx:U N.λy:U N.x;y

(e₁, e₂) e₁ During^(a) e₂ During λx:U N.λy:U N.x∥y

(e₁, e₂) If e₁ Then e₂ Test λx:U N.λy:U N.

(e₁,e₂, e₃) Else e₃ λz:U N.if x == unit then y else z e₁ PThen e₂ Thenλx:U N.λy:U N.if x ==

(e₁, e₂) unit then y else none e₁ PElse e₂ Else λx:U N.λy:U N.if x ==

(e₁, e₂) none then y else unit e₁ PBefore e₂ Before λx:U N.λy:U N.x;y

(e₁, e₂) *(e) n. a. n. a.

(e)

[0201] Note that the second section of the table above definesoperations which are polymorphic with respect to the application. Forinstance, if e:t₁

t₂ and e′:t′z,14 t,₂ then, the composition (assuming it is well typed) ePBefore e′ has a type t₁⊕t′₁

t₂

t′₂ which is a subtype of both original types by property of ⊕ and

: $\begin{matrix}\frac{{t_{2} \otimes t_{2}^{\prime}} \preccurlyeq {t_{2}\quad t_{1}} \preccurlyeq {t_{1} \oplus t_{1}^{\prime}}}{{t_{1} \oplus {t_{1}^{\prime}{t_{2} \otimes t_{2}^{\prime}}}} \preccurlyeq {t_{1}t_{2}}} & \left\lbrack {{\nabla{- {sub}}}\quad 2} \right\rbrack \\\frac{{t_{2} \otimes t_{2}^{\prime}} \preccurlyeq {t_{2}^{\prime}\quad t_{1}^{\prime}} \preccurlyeq {t_{1} \oplus t_{1}^{\prime}}}{{t_{1} \oplus {t_{1}^{\prime}{t_{2} \otimes t_{2}^{\prime}}}} \preccurlyeq {t_{1}^{\prime}t_{2}^{\prime}}} & \left\lbrack {{\nabla{- {sub}}}\quad 2} \right\rbrack\end{matrix}$

[0202] This is an interesting property from the polymorphic reuse pointof view. In particular, this property is required for the composition ofrecursive parameters since it guarantees the re-entrance of the fixpoint (from the type checking point of view).

[0203] The following table sets forth typing rules (i.e., typecombination relations) of formal parameters for composition operatorsand functional abstractions, in which the meta symbols are given as: *,⋄ ε {⊕,

}. operand

*_(E)

prefixes example arity result arity result λ λx:t.e n lambda 1 λ-fixλ-fix fixf(x:t) = e n λ-FIX — — mixed n λ-fix — —

[0204] The following table sets forth typing rules (i.e., typecombination relations) of formal parameters for composition operatorsand procedural abstractions, in which the meta symbols are given as: *,⋄ ε {⊕,

}. operand

prefixes examples arity result arity result arity result arity result ∇∇x:t₁,y:t₂.e n ∇ 1 ∇ 1 ∇ 2 ∇ ∇-fix point fixf(x:t₁,y:t₂)=e n ∇-fix 1∇-fix 1 ∇-fix — — mixed — n ∇-fix — — — — — —

[0205] H. Safety Properties Of The Calculus

[0206] This section first proves a general type preservation propertyfor the core calculus C. Then this section sets forth a strong typesoundness on a restricted functional calculus F (called the corecalculus: without fix point construction). Subsequently this sectionsets forth a weak soundness on C/F(E), a subset of C obtained byrestricting composition patterns E to F.

[0207] H.1 General Type Preservation Property

[0208] Definition 5: Soundness of an execution environment S withrespect to a typing environment γ, (written |├ S:γ) is given by:

[0209] |├ S:γ iff ∀x^(v)ε S, γ

x::t and γ

v::t

[0210] Theorem 1: Type preservation (subject reduction):

[0211] for all e, γ, S, such that γ

e::t and |├ S:γ

[0212] then S ├ e→S′ ├ e′ implies γ

e′::t and |├ S′:γ

[0213] Proof: Uses a structural induction. All typing cases forprogressing terms are considered.

[0214] H.2 Strong Type Soundness of the Core Calculus

[0215] Lemma 1: Reduction steps decrease the complexity of terms. (Givena relevant complexity measure of terms,

[0216] |.|:F→Nat, then if e→e′, then |e′|<|e|).

[0217] Proof: As no fix point constructions are allowed, it can be shownthat each computation step reduces the complexity of the term (this usesan inductive structural complexity measurement function such that |e|>0(e is not a value and |v|=0).

[0218] Theorem 2: Progression of well typed terms e of F. (if Ø

e:t then if e is not a value, e→e′).

[0219] Proof: Uses a structural induction. All typing cases areconsidered.

[0220] Theorem 3: Strong type soundness for F. (For all term Ø

e, if e:t then e

v)

[0221] Proof: If e is a value, then the proof is obvious. Otherwise, theprogress theorem 2 insure that e will evolve, and the type preservationtheorem says that it preserves the type. Lemma 1 says that eachintermediate term has a complexity that decreases down to zero (value).

[0222] H.3 Weak Type Soundness Of The Whole Calculus C/F( E)

[0223] The calculus C/F(E) is weakly sound, which means that for a giventerm e that is well typed in a given environment, if the computation ofe in a valid execution environment terminates, then the result isnecessarily a value.

[0224] Theorem 4: Progression of well typed terms:

[0225] for all e, γ, S such that γ

e:t, |├ S:γ

[0226] then if e is not a value, necessarly S ├ e→S′ ├ e′

[0227] Proof: In this proof the technical difficulty relies in thecomputation of composition operators, since the numerators of [c1] and[c2] must be themselves terminating computations. This means that thetransition c1, c2 might never occur (i.e., it may be stuck in a state)if the computation is endless. But as E is a term of F, then the strongsoundness theorem 3 guarantees the termination, thus the transitions c1and c2.

[0228] Corollary 1: Well typed closed normal terms are values:

[0229] if γ

e:t,|├ S:γ and S ├ e

, then e is a value.

[0230] Proof: It is made by showing logical equivalence of the progresstheorem 4. This last theorem 4 can be written under the propositionalform a ⊥ b

c and our corollary as a ⊥

c

b, where a is “Ø

e:t”, b is “e is not a value” and c is “e→e′”. By rewriting theimplications, the first form is equivalent to

c) and the second to

(a ⊥

c ⊥

c). This is easily amenable to

(a ⊥ b ⊥

c).

[0231] Theorem 5: Weak type soundness of C/F(E):

[0232] For all e, γ, S, if γ

e:t, |├ S:γ and S ├ e

S′ ├ e′

, then e′ is a value

[0233] Proof: By induction on the length “i” of the derivation path e

e′

and by considering two cases: e is a value (is an obvious proof), and eis not a value. In the case e is not a value, the progress theorem 4says that there is a transition step, and the subject reduction(theorem 1) says that the derived term is well typed. This reasoning canbe iterated until the final form is reached. At this point, thecorollary 1 raises the expected result.

[0234] I. Polymorphic Composition of Records

[0235] This section illustrates the benefits of composing record datastructures and associated types. Records are well known as a powerfulmodeling tool.

[0236] I.1 Definition

[0237] The following definitions illustrate how to build record termsand how to access a record having a name “m”.

[0238] Definition 6: Syntax Of Expression “e” And Type “t” e ::=<m₁=e₁,...,m_(n)=e_(n)> a record term, with m_(i) as member names ::=e.m acces to the content of member “m” t ::= <m₁:t₁,...,m_(n):t_(n)>record types

[0239] Records can be understood as composite data structures in whichsub-elements are stored under a labeled identifier. This offers orderinsensitive, easy to memorize ways of handling structured information,both from the storage and access point of view. For example defining:

[0240] Person

<name: string, firstname: string>

[0241] allows the modeling of a person such as (note the order is not ofimportance in this instance):

[0242] Jo

<firstname: ‘John’, name: ‘Doe’>

[0243] In addition, as is known in the art, subtype relations may bedefined on record data types. The following record type illustrates anexample of a subtype relation while remaining consistent when readingand writing to access members:${{AwardWinner}\overset{def}{=}{< {{name}\text{:}\quad {string}}}},{{firstname}\text{:}\quad {string}},{{{prize}\text{:}\quad {string}} >}$

This record type continues to allow modeling of person and memberaccess:${{P1}\overset{def}{=}{{\nabla p}\text{:}\quad {Person}}},{s\text{:}\quad {{string}\quad.\left( {s:=\quad {{p.\quad {firstname}} +^{\quad {''''}}{+ \quad {p.\quad {name}}}}} \right)}}$

with for example Jo, Do, and Ro: ${\begin{matrix}{{{Do}\overset{def}{=}{{< {name}} = {``{Knuth}"}}},{{firstname} = {``{Donald}"}},{{prize} = {{``{{Alan}\quad {Turing}\quad {Award}}"} >}}} \\{{{Ro}\overset{ref}{=}{{< {firstname}} = {``{Robin}"}}},{{name} = {``{Milner}"}},{{prize} = {{``{{Alan}\quad {Turing}\quad {Award}}"} >}}}\end{matrix}\quad}\quad$

Definition 7: Record Typing$\frac{\gamma \vartriangleright {{e_{1}{::}\quad t_{1}}\quad \ldots \quad \gamma} \vartriangleright {e_{n}\quad {::}\quad t_{n}}}{{{\gamma \vartriangleright < m_{1}} = e_{1}},\ldots,{m_{n} = {e_{n} > {{::}{< {m_{1}:t_{1}}}}}},\ldots,{m_{n}:{t_{n} >}}}\lbrack{Rec}\rbrack$

Definition 8: Record Subtyping:$\frac{{\forall{m_{i}\quad {\exists m_{j}^{\prime}}}} = \left. m_{i} \middle| {\gamma \vartriangleright t_{i} \preccurlyeq t_{j}^{\prime}} \right.}{{\gamma \vartriangleright < {m_{1}:t_{1}}},\ldots,{m_{n}:{t_{n} > \preccurlyeq < {m_{1}^{\prime}:t_{1}^{\prime}}}},\ldots,{m_{k}^{\prime}:{t_{k} >}}}\left\lbrack {S\text{-}{Rec}} \right\rbrack$

Note that dom(< m₁:t₁, . . ., m_(n):t_(n)>) = {m₁, . . ., m_(n)}Property 1: Intersection of record types: $\begin{matrix}\begin{matrix}{{\forall R},R^{\prime}} \\\quad\end{matrix} & {\quad \left\{ \begin{matrix}{{R = {< {m_{1}:t_{1}}}},\ldots,{m_{n}:{t_{n} >}}} \\{{R^{\prime} = {< {m_{1}:t_{1}}}},\ldots,{m_{k}:{t_{k} >}}}\end{matrix} \right.}\end{matrix}\quad$

thenR ⊗ R^(′) =  < m₁ : t₁ ⊗ t_(i)^(′), m_(l) : t_(l), m_(p) : t_(p)^(′)>

with all m_(i), m_(l), m_(p) such that $\begin{matrix}{{m_{i} \in {{{dom}(R)}\bigcap{{dom}\left( R^{\prime} \right)}}},} \\{{m_{l} \in {{{dom}(R)}\backslash {{dom}\left( R^{\prime} \right)}}},} \\{m_{p} \in {{{dom}\left( R^{\prime} \right)}\backslash {{dom}(R)}}}\end{matrix}\quad$

[0244] Proof: Performed by application of [S-Rec].

[0245] I.2 Using Record Polymophism in Pam Composition

[0246] Let PrizeWinner be: <name: string, year: int, prize: string>

[0247] then the Property 1 in Section I.1 provides that Person

PrizeWinneris:

[0248] <firstname: string, name: string, year: int, prize: string>

[0249] which is a record type that models information found in bothinitial records. This is particularly useful because composition usingthe

operator permits extension of the signature thereby enriching thecomputational environment. Defined below is a pam P₂ that computes astring representation of prize winner:

∇ w: PrizeWinner, s: string. s:=s+w.name+“won the”+w.prize+“prizein”+w.year

[0250] Now P₂(<name=“Milner”, year=“1991”, prize=“Alan Turing Award”)will return: “Milner won the Alan Turing Award prize in 1991.” with thefollowing composition:

P

∇ x: T, y:string.(y:=y+“:”)

P₃

P₁ Before P Before P₂

[0251] Note also the type P₃ is defined as:

φ

P₃::Person

PriceWinner

string

EXAMPLE 1:

P ₃(<name=“Milner”, year=“1991, firstname=“Robin”, prize=“Alan TuringAward”>

[0252] will return: “Robin Milner: Milner won the Alan Turing Awardprize in 1991”.

[0253] As shown in this example, both P₁ and P₂ operate with differentrecord types while their composition operates with a mixture of bothrecords. In addition, the example is formally well typed. For instance,proposing an integer value for year (e.g., the integer 1991 instead ofthe string “1991”) would prevent finding a type for this example.

[0254] J. Illustration Of A Modeling Tree Transformer

[0255] This section uses pattern matching expressions described in U.S.patent application Ser. No. 10/046,314, entitled “Symmetrical StructuralPattern Matching”, which is incorporated herein by reference. Forexample, the syntactic notation e₁#f

e₂ evaluates to expression e₂ if the result of expression e₁ matchesagainst the filter f; otherwise, the rule evaluates to the distinguishedvalue none.

[0256] Filters can be recursively constructed and thus can reacharbitrary complexity levels. For example, some basic filters are “%e”(which matches any value equal to the result of e) and “? x” (whichmatches any value and stores the resulting value into x). A recordfilter is noted <m₁=f₁, . . . , m_(n)=f_(n)> where f_(i) are filters,and matches against any record value <m₁=v₁, . . . , m_(n)=v_(n)> ifevery v_(i) matches f_(i).

[0257] The following recursive definition (where recursive types areassumed hereafter in this example to be handled by the type system)models binary trees where nodes are labeled by any type of value (T),and where leaves of the binary tree are strings:

β(<label:τ, left:β, right:β>|string)

[0258] where such types allow for instance the modeling of syntactictrees that are found in programming languages. For example as shown inFIG. 5, the arithmetic expression “a=b+10* c” can be encoded as a binarytree syntactically at 502 and illustratively at 504.

[0259] The following abstraction of a “top-down recursive tree visitor”does not perform any transformation but instead visits all nodes andreconstructs an identical tree: V = fixV(x:β,y:β)=[| x ♯ <label=?lab,left=?l, right=?r>

y :=<label=lab, left=V(l), right=V(r)>, y := x |]

[0260] The following transformer A changes “+” labels in a binary treeinto the numeric code ADD:

t ₁=fixT ₁(x:β, y:β)=(x # <label=% “+”, left=?l, right=?

r>

y:=<label=Add, left=T ₁(l), right=T ₁(r)>)

A=t₁ else V

[0261]FIG. 6 illustrates the resulting binary tree syntactically at 602and illustratively at 604 when the transformer A is applied to thebinary tree shown in FIG. 5.

[0262] The following transformer B changes “*” labels into the numericcode MUL:

t ₂=fixT ₂(x:β, y:β)=(x# <label=% “*”, left=?l, right=?

r>

y:=<label=MUL, left=T ₂(l), right=T ₂(r)>)

B=t₂ else V

[0263]FIG. 7 illustrates the resulting binary tree syntactically at 702and illustratively at 704 when the transformer B is applied to thebinary tree shown in FIG. 5.

[0264] The composition of the transformers A and B is defined as:

A ∘ B=∇ x:β, y:β.y:=B(A(x))

[0265] Using the composition operator “else” defined in Section G above,the composition of the transformers A and B is defined as:

A ∘ B=t₁ else t₂ else V

[0266] which is computationally equivalent to:

fixT(x:β, y:β)=[|

x # <label=% “+”, left=?l, right=?

r>

y:=<label=ADD, left=T(l), right=T(r)>,

x # <label=% “*”, left=?l, right=?

r>

y:=<label=MUL, left=T(l), right=T(r)>,

x # <label=?lab, left=?l, right=?

r>

y:=<label=lab, left=T(l), right=T(r)>,

y:=x |]

[0267]FIG. 8 illustrates the resulting binary tree syntactically at 802and illustratively at 804 when the composition of transformers A and Bis applied to the binary tree shown in FIG. 5.

[0268] K. Miscellaneous

[0269] Using the foregoing specification, the invention may beimplemented as a machine (or system), process (or method), or article ofmanufacture by using standard programming and/or engineering techniquesto produce programming software, firmware, hardware, or any combinationthereof.

[0270] Any resulting program(s), having computer-readable program code,may be embodied within one or more computer-usable media such as memorydevices or transmitting devices, thereby making a computer programproduct or article of manufacture according to the invention. As such,the terms “article of manufacture” and “computer program product” asused herein are intended to encompass a computer program existent(permanently, temporarily, or transitorily) on any computer-usablemedium such as on any memory device or in any transmitting device.

[0271] Executing program code directly from one medium, storing programcode onto a medium, copying the code from one medium to another medium,transmitting the code using a transmitting device, or other equivalentacts may involve the use of a memory or transmitting device which onlyembodies program code transitorily as a preliminary or final step inmaking, using, or selling the invention.

[0272] Memory devices include, but are not limited to, fixed (hard) diskdrives, floppy disks (or diskettes), optical disks, magnetic tape,semiconductor memories such as RAM, ROM, Proms, etc. Transmittingdevices include, but are not limited to, the Internet, intranets,electronic bulletin board and message/note exchanges, telephone/modembased network communication, hard-wired/cabled communication network,cellular communication, radio wave communication, satellitecommunication, and other stationary or mobile networksystems/communication links.

[0273] A machine embodying the invention may involve one or moreprocessing systems including, but not limited to, CPU, memory/storagedevices, communication links, communication/transmitting devices,servers, I/O devices, or any subcomponents or individual parts of one ormore processing systems, including software, firmware, hardware, or anycombination or subcombination thereof, which embody the invention as setforth in the claims.

[0274] It will be appreciated that various other alternatives,modifications, variations, improvements or other such equivalents of theteachings herein that may be presently unforeseen, unappreciated orsubsequently made by others are also intended to be encompassed by theclaims.

1. A method for composing programming abstractions, comprising: defininga composition operation for composing a first abstraction and a secondabstraction with a selected composition operator; each abstractionhaving a form, a prefix, and at least one expression; unfolding theexpressions from the first and the second abstractions by: (a) removingthe prefix of each abstraction, and (b) substituting formal parameternames in each expression with a common parameter name to define openvariables; transforming the unfolded expressions to a reduced expressionusing a composition pattern that tunes semantics of the selectedcomposition operator; selecting a prefix that depends on the selectedcomposition operator and the form of the first abstraction and thesecond abstraction; the selected prefix having a formal parameter with atype; and nesting the reduced expression in a third abstraction thatcomposes the first abstraction and the second abstraction by: (i)appending the selected prefix to the reduced expression, (ii) bindingthe open variables of the reduced expression to the formal parameter ofthe selected prefix, and (iii) computing the type of the formalparameter of the selected prefix.
 2. The method according to claim 1,wherein the selected composition operator applies to operands thatcomprise at least one recursive functional abstraction.
 3. The methodaccording to claim 1, wherein the selected composition operator is

as defined by: $\begin{matrix}{\left( {z\quad {fresh}} \right)\frac{E{e_{1}\left\lbrack {z/x_{1}} \right\rbrack}\cdots \quad {e_{n}\left\lbrack {z/x_{n}} \right\rbrack}}{\left. {\left( {{\lambda \quad x_{1}\text{:}{t_{1} \cdot e_{1}}},\ldots \quad,{\lambda \quad x_{n}\text{:}{t_{n} \cdot e_{n}}}} \right)}\rightarrow{\lambda \quad z\text{:}{t^{x} \cdot }} \right.}} & \lbrack{c1}\rbrack\end{matrix}$

where: “λ x_(n):t_(n).e_(n)” is a lambda abstraction with prefix “λx:t”, in which “λ” identifies a form of abstraction, “x” identifies aformal parameter of type “t”, and “e” is the expression of theabstraction; “e[z/x ]” means substitute x_(n) for z in the expressione_(n), “

” means the terminal form of an operation reduces to a value, “

” identifies a type combination relation, “e₁

e₂

” defines a lazy application in which the expression e₂ is passed by afunction without first being computed, “e” is a composition pattern: 4.The method according to claim 3, wherein the selected compositionoperator

applies to operands that comprise at least one recursive functionalabstraction.
 5. The method according to claim 1, wherein the selectedcomposition operator is

as defined by: (f fresh)

(λx:t.e)→fixf(x:t)=f(e)   [c3] where: “λ x:t.e” is a lambda abstractionwith prefix “λ x:t”, in which “λ” identifies a form of abstraction, “x”identifies a formal parameter of type “t”, and “e” is the expression ofthe abstraction; “f” is the logical name of a function; and “fix”identifies that the expression “e” is recursive, to permit use of itselfthrough the logical name “f”.
 6. The method according to claim 1,wherein the selected composition operator is

as defined by: $\begin{matrix}{{t_{1}^{\prime}{\bigstar t}_{2}} \neq \bot\frac{{\Phi_{E}\left( {{e_{1}\left\lbrack {x/y_{1}} \right\rbrack},{e_{2}\left\lbrack {x/x_{2}} \right\rbrack}} \right)}}{\begin{matrix}{{\left( {{{\nabla\quad x_{1}}\text{:}t_{1}},{y_{1}\text{:}{t_{1}^{\prime} \cdot e_{1}}},{{\nabla\quad x_{2}}\text{:}t_{2}},{y_{2}\text{:}{t_{2}^{\prime} \cdot e_{2}}}} \right)}->} \\{{{\nabla\quad x_{1}}\text{:}t_{1}},{{y_{2}\text{:}{t_{2}^{\prime} \cdot {var}}\quad x} = {{{init}\left( {t_{1}^{\prime}{\bigstar t}_{2}} \right)} \cdot e}}}\end{matrix}}} & \lbrack{c6}\rbrack\end{matrix}$

where: “∇ x:t, y:t′.e” is a nabla abstraction with prefix “∇ x:t, y:t′”,in which “∇” identifies a form of abstraction, “x” and “y” identify aparameter of type “t” and “t′” respectively, and “e” is the expressionof the abstraction; “Φ” is a parametric function that performs asyntactic transformation of n terms into a new term; “E” is acomposition pattern.
 7. The method according to claim 1, wherein theselected composition operator is

as defined by: $\begin{matrix}\frac{{\Phi_{Iter}(e)}^{\prime}}{{{\left( {{{\nabla x}\text{:}t},{y\text{:}{t^{\prime} \cdot e}}} \right)}->{{\nabla x}\text{:}t}},{y\text{:}{t^{\prime} \cdot ^{\prime}}}} & \lbrack{c7}\rbrack\end{matrix}$

where: “∇ x:t, y:t′.e” is a nabla abstraction with prefix “∇ x:t, y:t′”,in which “∇” identifies a form of abstraction, “x” and “y” identify aparameter of type “t” and “t′” respectively, and “e” is the expressionof the abstraction; and “Φ is a parametric function that performs asyntactic transformation of n terms into a new term.
 8. The methodaccording to claim 7, wherein the selected composition operator

applies to a recursive nabla abstraction.
 9. The method according toclaim 1, wherein the selected composition operator is

as defined by: {overscore (

(∇ x:t, y:t′.e)→∇ y:t′, x:t.e)}  [c9] where: “∇ x:t, y:t′.e” is a nablaabstraction with prefix “∇ x:t, y:t′”, in which “∇” identifies a form ofabstraction, “x” and “y” identify a parameter of type “t” and “t′”respectively, and “e” is the expression of the abstraction.
 10. Themethod according to claim 9, wherein the selected composition operator

applies to a recursive nabla abstraction.
 11. An apparatus for composingprogramming abstractions, comprising: means for defining a compositionoperation for composing a first abstraction and a second abstractionwith a selected composition operator; each abstraction having a form, aprefix, and at least one expression; means for unfolding the expressionsfrom the first and the second abstractions by: (a) removing the prefixof each abstraction, and (b) substituting formal parameter names in eachexpression with a common parameter name to define open variables; meansfor transforming the unfolded expressions to a reduced expression usinga composition pattern that tunes semantics of the selected compositionoperator; means for selecting a prefix that depends on the selectedcomposition operator and the form of the first abstraction and thesecond abstraction; the selected prefix having a formal parameter with atype; and means for nesting the reduced expression in a thirdabstraction that composes the first abstraction and the secondabstraction by: (i) appending the selected prefix to the reducedexpression, (ii) binding the open variables of the reduced expression tothe formal parameter of the selected prefix, and (iii) computing thetype of the formal parameter of the selected prefix.
 12. The apparatusaccording to claim 11, wherein the selected composition operator appliesto operands that comprise at least one recursive functional abstraction.13. The apparatus according to claim 11, wherein the selectedcomposition operator is

as defined by: $\begin{matrix}{\left( {z\quad {fresh}} \right)\frac{E{e_{1}\left\lbrack {z/x_{1}} \right\rbrack}\cdots \quad {e_{n}\left\lbrack {z/x_{n}} \right\rbrack}}{\left. {\left( {{\lambda \quad x_{1}\text{:}{t_{1} \cdot e_{1}}},\ldots \quad,{\lambda \quad x_{n}\text{:}{t_{n} \cdot e_{n}}}} \right)}\rightarrow{\lambda \quad z\text{:}{t^{x} \cdot }} \right.}} & \lbrack{c1}\rbrack\end{matrix}$

where: “λ x_(n):t_(n).e_(n)” is a lambda abstraction with prefix “λx:t”, in which “λ” identifies a form of abstraction, “x” identifies aformal parameter of type “t”, and “e ” is the expression of theabstraction; “e_(n)[z/x_(n)]” means substitute x_(n) for z in theexpression e_(n), “

” means the terminal form of an operation reduces to a value, “

” identifies a type combination relation, “e₁

e₂

” defines a lazy application in which the expression e₂ is passed by afunction without first being computed, “E” is a composition pattern. 14.The apparatus according to claim 13, wherein the selected compositionoperator

applies to operands that comprise at least one recursive functionalabstraction.
 15. The apparatus according to claim 11, wherein theselected composition operator is

as defined by: (f fresh)

(λx:t.e)→fixf(x:t)=f(e)   [c3] where: “λ x:t.e” is a lambda abstractionwith prefix “λ x:t”, in which “λ” identifies a form of abstraction, “x”identifies a formal parameter of type “t”, and “e” is the expression ofthe abstraction; “f” is the logical name of a function; and “fix”identifies that the expression “e” is recursive, to permit use of itselfthrough the logical name “f”.
 16. The apparatus according to claim 11,wherein the selected composition operator is

as defined by: $\begin{matrix}{{t_{1}^{\prime}{\bigstar t}_{2}} \neq \bot\frac{{\Phi_{E}\left( {{e_{1}\left\lbrack {x/y_{1}} \right\rbrack},{e_{2}\left\lbrack {x/x_{2}} \right\rbrack}} \right)}}{\begin{matrix}{{\left( {{{\nabla\quad x_{1}}\text{:}t_{1}},{y_{1}\text{:}{t_{1}^{\prime} \cdot e_{1}}},{{\nabla\quad x_{2}}\text{:}t_{2}},{y_{2}\text{:}{t_{2}^{\prime} \cdot e_{2}}}} \right)}->} \\{{{\nabla\quad x_{1}}\text{:}t_{1}},{{y_{2}\text{:}{t_{2}^{\prime} \cdot {var}}\quad x} = {{{init}\left( {t_{1}^{\prime}{\bigstar t}_{2}} \right)} \cdot e}}}\end{matrix}}} & \lbrack{c6}\rbrack\end{matrix}$

where: “∇ x:t, y:t′.e” is a nabla abstraction with prefix “∇ x:t, y:t′”,in which “∇” identifies a form of abstraction, “x” and “y” identify aparameter of type “t” and “t′” respectively, and “e” is the expressionof the abstraction; “Φ” is a parametric function that performs asyntactic transformation of n terms into a new term; “E” is acomposition pattern.
 17. The apparatus according to claim 11, whereinthe selected composition operator is

as defined by: $\begin{matrix}\frac{{\Phi_{Iter}(e)}^{\prime}}{{{\left( {{{\nabla x}\text{:}t},{y\text{:}{t^{\prime} \cdot e}}} \right)}->{{\nabla x}\text{:}t}},{y\text{:}{t^{\prime} \cdot ^{\prime}}}} & \lbrack{c7}\rbrack\end{matrix}$

where: “∇ x:t, y:t′.e” is a nabla abstraction with prefix “∇ x:t, y:t′”,in which “∇” identifies a form of abstraction, “x” and “y” identify aparameter of type “t” and “t′” respectively, and “e” is the expressionof the abstraction; and “Φ” is a parametric function that performs asyntactic transformation of n terms into a new term.
 18. The apparatusaccording to claim 11, wherein the selected composition operator is a asdefined by: {overscore (

(∇x:t, y:t′.e)→∇y:t′, x:t.e)}  [c9] where: “∇ x:t, y:t′.e” is a nablaabstraction with prefix “∇ x:t, y:t′”, in which “∇” identifies a form ofabstraction, “x” and “y” identify a parameter of type “t” and “t′”respectively, and “e ” is the expression of the abstraction.
 19. Anarticle of manufacture for use in a machine, comprising: a memory;instructions stored in the memory for composing programming abstractionscomprising: defining a composition operation for composing a firstabstraction and a second abstraction with a selected compositionoperator; each abstraction having a form, a prefix, and at least oneexpression; unfolding the expressions from the first and the secondabstractions by: (a) removing the prefix of each abstraction, and (b)substituting formal parameter names in each expression with a commonparameter name to define open variables; transforming the unfoldedexpressions to a reduced expression using a composition pattern thattunes semantics of the selected composition operator; selecting a prefixthat depends on the selected composition operator and the form of thefirst abstraction and the second abstraction; the selected prefix havinga formal parameter with a type; and nesting the reduced expression in athird abstraction that composes the first abstraction and the secondabstraction by: (i) appending the selected prefix to the reducedexpression, (ii) binding the open variables of the reduced expression tothe formal parameter of the selected prefix, and (iii) computing thetype of the formal parameter of the selected prefix.
 20. The article ofmanufacture according to claim 19, wherein the selected compositionoperator applies to operands that comprise at least one recursivefunctional abstraction.